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(54) Service interaction using properties attached to documents 



(57) A document management system is provided 
which organizes, stores and retrieves documents 
according to properties attached to the documents. A 
property attachment mechanism allows a user to attach 
arbitrary static and active properties to a document. The 
active properties include executable code which acti- 
vates an external service in response to a triggering 
event which is predefined by the user, such as an oper- 
ation performed on the document. When the operation 
is applied to the document, the operation is compared to 
the active properties of the document to determine if it is 
a triggering event. If an active property is triggered, its 
code is executed which automatically invokes an exter- 
nal service that executes independently from the opera- 
tion. The results of the service are sent back to the 
document management system and the operation is 
then continued. In this manner, a user interacts directly 
with a document rather than locating, loading and exe- 
cuting an external service to be applied to the docu- 
ment. The user and/or other applications are unaware 
of the external service being processed. 



B . .lOa ^10b ^10n .,12a ^12b ^Ub ✓lln 



(PRINCIPAL 1) (PRINCIPAL 2) (PRINCIPALS) (PRINCIPAL n) 
18s 



26- 





EXTERNAL DOCUMENT STORAGE 

FIG.3 




Primed by Xerox (UK) Business Services 
2.16.7/3.6 



BNSDOCID: <EP 0987636 A2_l_> 



EP 0 987 636 A2 



Description 

Background of the Invention 

[0001 ] The present invention is directed to document 
management systems. It finds particular application to a 
system and method which provides service interaction 
to a document through the use of properties attached to 
the document and will be described with particular refer- 
ence thereto. 

[0002] The inventors have recognized that a large 
amount of a user's interaction with a computer has to do 
with document management, such as storing, filing, 
organizing and retrieving information from numerous 
electronic documents. These documents may be found 
on a local disc, on a network system file server, an e- 
mail file server, the world wide web, or a variety of other 
locations. Modern communication delivery systems 
have had the effect of greatly increasing the flow of doc- 
uments which may be incorporated within a user's doc- 
ument space, thereby increasing the need for better 
tools to visualize and interact with the accumulated doc- 
uments. 

[0003] The most common tools for organizing a docu- 
ment space rely on a single fundamental mechanism 
known as hierarchical storage systems, wherein docu- 
ments are treated as files that exist in directories or fold- 
ers, which are themselves contained in other 
directories, thereby creating a hierarchy that provides 
the structure for document space interactions. Each 
directory in a hierarchy of directories, will commonly 
contain a number of individual files. Typically, files and 
directories are given alpha-numeric, mnemonic names 
in large storage volumes shared via a network. In such 
a network, individual users may be assigned specific 
directories. 

[0004] A file located in a sub-directory is located by its 
compound path name. For example, the character 
String D:\TREB LIMB\BRANCH\TWIG\LEAF.FIL could 
describe the location of a file LEAF.FIL whose immedi- 
ate directory is TWIG and which is located deep in a 
hierarchy of files on the drive identified by the letter D. 
Each directory is itself a file containing file name, size, 
location data, and date and time of file creation or 
changes. 

[0005] Navigation through a file system, to a large 
degree, can be considered as navigation through 
semantic structures that have been mapped onto the 
file hierarchy. Such navigation is normally accomplished 
by the use of browsers and dialog boxes. Thus, when a 
user traverses through the file system to obtain a file 
(LEAF.FIL), this movement can be seen not only as a 
movement from one file or folder to another, but also as 
a search procedure that exploits features of the docu- 
ments to progressively focus on a smaller and smaller 
set of potential documents. The structure of the search 
is mapped onto the hierarchy provided by the file sys- 
tem, since the hierarchy is essentially the only existing 



mechanism available to organize files. However, docu- 
ments and files are not the same thing. 
[0006] Since files are grouped by directories, associ- 
ating a single document with several different content 

s groupings is cumbersome. The directory hierarchy is 
also used to control the access to documents, with 
access controls placed at every node of the hierarchy, 
which makes it difficult to grant file access to only one or 
a few people. In the present invention, separation of a 

w document's inherent identity from its properties, includ- 
ing its membership in various document collections, 
alleviates these problems. 

[0007] Other drawbacks include that existing hierar- 
chical file systems provide a "single inheritance" struc- 

15 ture. Specifically, files can only be in one place at a time, 
and so can occupy only one spot in the semantic struc- 
ture. The use of links and aliases are attempts to 
improve upon such a limitation. Thus, while a user's 
conception of a structure by which files should be 

20 organized may change over time, the hierarchy 
described above is fixed and rigid. While moving individ- 
ual files within such a structure is a fairly straightforward 
task, reorganizing large sets of files is much more com- 
plicated, inefficient and time consuming. From the fore- 

25 going it can be seen that existing systems do not 
address a user's need to after a file structure based on 
categories which change over time. At one moment a 
user may wish to organize the document space in terms 
of projects, while at some time in the future the user may 

30 wish to generate an organization according to time 
and/or according to document content. A strict hierar- 
chical structure does not allow management of docu- 
ments for multiple views in a seamless manner resulting 
in a decrease in the efficiency of document retrieval. 

35 [0008] Existing file systems also support only a single 
model for storage and retrieval of documents. This 
means a document is retrieved in accordance with a 
structure or concepts given to it by its author. On the 
other hand, a user ™ who is not the author --- may wish 

40 to retrieve a document in accordance with a concept or 
grouping different from how the document was stored. 
[0009] Further, since document management takes 
place on a device having computational power, there 
would be benefits to harnessing the computational 

45 power to assist in the organization of the documents. 
For example, by attaching a spell-checker property to a 
document, it can extend the read operation of a docu- 
ment so that the content returned to the requesting 
application will be correctly spelled. 

so [001 0] The inventors are aware that others have stud- 
ied the area of document management/storage sys- 
tems. 

[0011] DMA is a proposed standard from AIIM 
designed to allow document management systems from 
55 different vendors to intemperate. The DMA standard 
covers both client and server interfaces and supports 
useful functionality including collections, versioning, 
renditions, and multiple-repository search. A look at the 
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APIs show that DMA objects (documents) can have 
properties attached to them. The properties are strongly 
typed in DMA and must be chosen from a limited set 
(string, int t date . . .)■ To allow for rich kinds of proper- 
ties, one of the allowable property types is another DMA 5 
object. A list type is allowed to build up big properties. 
Properties have a unique IDs in DMA. Among the differ- 
ences which exist to the present invention, is the prop- 
erties are attached to documents without differentiation 
about which user would like to see them; properties are 10 
stored in the document repository that provides the 
DMA interface, not independently from it. Similarly, 
DMA does not provide support for active properties. 
[001 2] WebDAV is another interface designed to allow 
an extended uniform set of functionality to be attached 75 
with documents available through a web server. Web- 
DAV is a set of extensions to the HTTP 1 . 1 protocol that 
allow Web clients to create and edit documents over the 
Web. It also defines collections and a mechanism for 
associating arbitrary properties with resources. Web- 20 
Dav also provides a means for creating typed links 
between any two documents, regardless of media type 
where previously, only HTML documents. could contain 
links. Compared to the present invention, although 
WebDAV provides support for collections, these are 25 
defined by extension (that is all components have to be 
explicitly defined); and although it provides arbitrary 
document properties, these live with the document itself 
and cannot be independently defined for different users, 
furthermore there is no support for active properties and 30 
are mostly geared toward having ASCII (or XML) val- 
ues. 

[001 3] DocuShare is a simple document management 
system built as a web-server by Xerox Corporation. It 
supports simple collections of documents, limited sets 35 
of properties on documents and support for a few non- 
traditional document types like calendars and bulletin 
boards. It is primarily geared toward sharing of docu- 
ments of small, self-defined groups (for the latter, it has 
support to dynamically create users and their permis- 40 
sions.) DocuShare has notions of content providers, but 
these are not exchangeable for a document. Content 
providers are associated with the type of the document 
being accessed. In DocuShare properties are static, 
and the list of properties that can be associated with a 45 
document depends on the document type. Users can- 
not easily extend this list. System administrators must 
configure the site to extend the list of default properties 
associated with document types, which is another con- 
trast to the present invention. Alsojn DocuShare prop- so 
erties can be visible to anyone who has read access for 
the collection in which the document is in. Properties 
are tightly bound to documents and it is generally diffi- 
cult to maintain a personalized set of properties for a 
document again a different approach than the one ss 
described in the present invention. 
[0014] An operating system "SPIN" from the Univer- 
sity of Washington allows users to inject code into the 



kernel that is invoked when an appropriate system call 
or system state occurs. (For example, users can inject 
code that alters paging decisions.) If it has already been 
done, their technology could be used to make it possible 
to inject code into the file system to invoke a user's code 
on read and write. Among the differences between 
SPIN and the concepts of present invention are that 
code injected into SPIN runs at the kernel level and 
users can only express their behaviors in a restricted, 
safe language in which it is not possible to do "bad 
things." As such, expressiveness is limited. On the other 
hand, the properties in the present invention run at the 
user level, and can have GUIs call out to third party 
libraries and in general be far more expressive than a 
kernel injected spindle. Further, the properties of the 
present invention are expressed in terms of documents, 
as in "I attach property X to Document Y" The SPIN 
system, on the other hand, extends a system call such 
as "read". The example behaviors mentioned above are 
more easily mapped into a system such as the present 
invention in which properties are explicitly attached to 
individual documents. 

[001 5] Other work which allows operating system calls 
to be extended into user's code include, the article 
"Interposition Agents: Transparently Interposing User 
Code and System Interface," by Michael B. Jones in 
Proceedings of the 14 th Symposium on Operating Sys- 
tems, Principles, Asheville, NC, December, 1993, pages 
80-93. The article "SLIC: An Extensibility System for 
Commodity Operating Systems," by Douglas P. Ghorm- 
ley, Steven H. Rodriguez, David Petrou, Thomas E. 
Anderson, which is to appear in the USENIX 1998 
Annual Technical Conference, New Orleans, LA, June 
1998. 

[0016] Further, the Windows NT (from Microsoft) has 
a function called "Filter Drivers" which, once installed, 
can see the accesses made to a file system. Installing 
filter drivers is a privileged operation, not available to 
normal users. As such, a user level mechanism, such as 
the document properties of the present invention and 
event dispatching architecture would be needed to allow 
users to express their desired behaviors. 
[0017] There are also systems which, in a very spe- 
cific domain, allow users to apply behaviors when docu- 
ments are accessed. An example is the Tandem e-mail 
system, which has a "screen cobal" language and has 
hooks to find out when events occur. This system allows 
users to code filters to do custom operations when doc- 
uments arrive and/or read. One of the differences 
between this system and the present invention, is that 
the Tandem system solves the problem in a specific 
domain and invokes only the user's behaviors when the 
documents are accessed via the mail application. In the 
present invention, the behaviors are invoked regardless 
of the application and regardless of the interface. 
[0018] The paper, "Finding and Reminding: File 
Organization From the Desktop", D. Barreau and B. 
Nardi, SIGCHI Bulletin, 27(3) July, 1995, reviews filing 
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and retrieval practices and discusses the shortcomings 
of traditional file and retrieval mechanisms. The paper 
illustrates that most users do not employ elaborate or 
deep filing systems, but rather show a preference for 
simple structures and "location-based searches", 5 
exploiting groupings of files (either in folders, or on the 
computer desktop) to express patterns or relationships 
between documents and to aid in retrieval. 
[0019] In response to the Barreau article, the article, 
"Find and Reminding Reconsidered", by S. Fertig, E. 10 
Freeman and D. Gelernter, SIGCHI Bulletin, 28(1) Jan- 
uary, 1996, defends deep structure and search queries, 
observing that location-based retrieval is, "nothing more 
than a user-controlled logical search." There is, how- 
ever, one clear feature of location-based searching is 
which adds to a simple logical search - in a location- 
based system, the documents have been subject to 
some sort of pre-categorization. Additional structure is 
then introduced into the space, and this structure is 
exploited in search and retrieval. 20 
[0020] The article "Information Visualization Using 3D 
Interactive Animation", by G. Robertson. S. Card and J. 
Mackinlay, Communications of the ACM 36(4) April, 
1993, discusses a location-based structure, an interest- 
ing feature is that it is exploited perceptually, rather than 2s 
cognitively This moves the burden of retrieval effort 
from the cognitive to the perceptual system. While this 
approach may be effective, the information that the sys- 
tems rely on is content-based, and extracting this infor- 
mation to find the structure can be computationally 30 
expensive. 

[0021] The article "Using a Landscape Metaphor to 
Represent a Corpus of Documents," Proc. European 
Conference on Spatial Information Theory, Elba, Sep- 
tember, 1 993, by M. Chalmers, describes a landscape 35 
metaphor in which relative document positions are 
derived from content similarity metrics. A system, dis- 
cussed in "Lifestr earns: Organizing your Electronic 
Life", AAAI Fall Symposium: Al Applications in Knowl- 
edge Navigation on Retrieval (Cambridge, MA), E. Free- 40 
man and S. Fertig, November, 1995, uses a timeline as 
the major organizational resource for managing docu- 
ment spaces. Lifestreams is inspired by the problems of 
a standard single-inheritance file hierarchy and seeks 
to use contextual information to guide document 45 
retrieval. However, Lifestreams replaces one superordi- 
nate aspect of the document (its location in the hierar- 
chy) with another (its location in the timeline). 
[0022] The article "Semantic File Systems" by Glifford 
et al., Proc. Thirteenth ACM Symposium of Operating so 
Systems Principals (Pacific Grove, CA) October, 1991, 
introduces the notion of "virtual directories" that are 
implemented as dynamic queries on databases of doc- 
ument characteristics. The goal of this work was to inte- 
grate an associating search/retrieval mechanism into a ss 
conventional (UNIX) file system. In addition, their query 
engine supports arbitrary "transducers" to generate 
data tables for different sorts of files. Semantic File Sys- 



tem research is largely concerned with direct integration 
into a file system so that it could extend the richness of 
command line programming interfaces, and so it intro- 
duces no interface features at all other than the file 
name/query language syntax. In contrast, the present 
invention is concerned with a more general paradigm 
based on a distributed, multi-principal property-based 
system and with how interfaces can be revised and aug- 
mented to deal with rt; the fact that the present invention 
can act as a file system is simply in order to support 
existing file system-based applications, rather than as 
an end in itself. 

[0023] DLITE is the Stanford Digital Libraries Inte- 
grated Task Environment, which is a user interface for 
accessing digital library resources as described in The 
Digital Library Integrated Task Environment" Technical 
Report SIDL-WP-1 996-0049, Stanford Digital Libraries 
Project (Palo Alto, CA) 1996, by S. Cousins et al. DLITE 
explicitly reifies queries and search engines in order to 
provide users with direct access to dynamic collections. 
The goal of DLITE, however, is to provide a unified inter- 
face to a variety of search engines, rather than to create 
new models of searching and retrieval. So although 
queries in DLITE are independent of particular search 
engines, they are not integrated with collections as a 
uniform organizational mechanism. 
[0024] Multivalent documents define documents as 
comprising multiple "layers" of distinct but intimately- 
related content. Small dynamically-loaded program 
objects, or "behaviors", activate the content and work in 
concert with each other and layers of content to support 
arbitrarily specialized document types. To quote from 
one of their papers, "A document management infra- 
structure built around a multivalent perspective can pro- 
vide an extensible, networked system that supports 
incremental addition of content incremental addition of 
interaction with the user and with other components, 
reuse of content across behaviors, reuse of behaviors 
across types of documents, and efficient use of network 
bandwidth." 

[0025] Multivalent document behaviors (analogs to 
properties) extend and parse the content layers, each of 
which is expressed in some format. Behaviors are 
tasked with understanding the formats and adding func- 
tionality to the document based on this understanding. 
In many ways, the Multivalent document system is an 
attempt at creating an infrastructure that can deal with 
the document format problem by incrementally adding 
layers of "understanding" of various formats. In contrast, 
the present invention has an explicit goal of exploring 
and developing a set of properties that are independent 
of document format. While properties could be devel- 
oped that could parse and understand content it is 
expected that most will be concerned with underlying 
storage, replication, security, and ownership attributes 
of the documents. Included among the differences 
between the present invention and the Multivalent con- 
cepts are that, the Multivalent document system 
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focuses on extensibility as a tool for content presenta- 
tion and new content-based behaviors; the present 
invention focuses on extensible and incrementally- 
added properties as a user-visible notion to control doc- 
ument storage and management. $ 
[0026] File systems known as the Andrew File System 
(AFS), Coda, and Ficus provide a uniform name space 
for accessing files that may be distributed and replicated 
across a number of servers. Some distributed file sys- 
tems support clients that run on a variety of platforms. 10 
Some support disconnected file access through cach- 
ing or replication. For example, Coda provides discon- 
nected access through caching, while Ficus uses 
replication. Although the immediately described distrib- 
uted file systems support document (or file) sharing, 15 
they have a problem in that a file's hierarchical 
pathname and its storage location and system behavior 
are deeply related. The place in the directory hierarchy 
where a document gets stored generally determines on 
which servers that file resides. 20 
[0027] Distributed databases such as Oracle, SQL 
Server, Bayou, and Lotus Notes also support shared, 
uniform access to data and often provide replication. 
Like some distributed file systems, many of today's 
commercial databases provide support for discon- 25 
nected operation and automatic conflict resolution. 
They also provide much better query facilities than file 
systems. However, distributed databases suffer the 
same problems as file systems in that the properties of 
the data, such as where it is replicated and how it is 30 
indexed and so on, are generally associated with the 
tables in which that data resides. Thus, these properties 
cannot be flexibly managed and updated. Also, the set 
of possible properties is not extensible. 
[0028] A digital library system, known as the Docu- 35 
mentum DocPage repository, creates a document 
space called a "DocBase." This repository stores a doc- 
ument as an object that encapsulates the document's 
content along with its attributes, including relationships, 
associated versions, renditions, formats, workflow char- 40 
acteristics, and security. These document objects can 
be infinitely combined and re-combined on demand to 
form dynamic configurations of document objects that 
can come from any source. 

[0029] DocPage supports organization of documents 45 
via folder and cabinet metaphors, and allows searching 
over both document content and attributes. The system 
also provides checkin/checkout-style version control, 
full version histories of documents, and annotations 
(each with its own attributes and security rules). The so 
system also supports workflow-style features including 
notification of updates. DocBase uses a replicated infra- 
structure for document storage (see: http://www.docu- 
mentum.com). 

[0030] Among the differences between Documentum 55 
DocPage and the present invention are: First, in the 
present system properties are exposed as a fundamen- 
tal concept in the infrastructure. Further, the present 



system provides for a radically extensible document 
property infrastructure capable of supporting an after- 
market in document attributes. Documentum seems to 
be rather closed in comparison; the possible attributes a 
document can acquire are defined a priori by the sys- 
tem and cannot be easily extended. Additionally, Docu- 
mentum does not have the vision of universal access to 
the degree of the present invention which supports 
near-universal access to document meta-data, if not 
document content. In comparison, the scope of Docu- 
mentum narrows to document access within a closed 
setting (a corporate intranet). 

[0031 ] Regarding the execution of an external service, 
a traditional way of invoking a service or program is to 
interact directly with the service, and possibly loading or 
referencing electronic document files as input. A user is 
burdened with having to know how to invoke the service 
and what parameters to use each time the user wishes 
to use the service. 

[0032] The present invention contemplates a new and 
improved method and system for automatically invoking 
an service for a document and which overcomes the 
above-referenced problems and others. 

Summary of the Invention 

[0033] A method of activating a service to be, per- 
formed on a document in response to a triggering event 
is provided. A property is logically attached to the docu- 
ment and is configured to activate a service which 
manipulates the document in response to the triggering 
event. An operation is associated to the property as the 
triggering event, where the operation is to be performed 
on the document which is initiated by an application. 
The service is independent from the application and is 
capable of manipulating the document without the appli- 
cation being aware of the manipulating. The application 
initiates the operation to be performed on the document 
and the operation is intercepted before being per- 
formed. The property attached to the document for 
which the operation is the triggering event is identified. 
The service associated to the property triggered by the 
operation is then activated and the service manipulates 
the document independent from the application. The 
operation is then performed on the manipulated docu- 
ment. 

[0034] In accordance with another aspect of the 
present invention, a method of activating a service to be 
performed on a document in response to a triggering 
event in a document management system is provided. A 
property is logically attached to the document where the 
property is configured to activate a service which 
manipulates the document in response to the triggering 
event. The triggering event is associated to the property 
such that the property invokes the service in response 
to an occurance of the triggering event. An occurrence 
of the triggering event is monitored and intercepted. The 
property attached to the document which has the trig- 
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gering event associated thereto is identified. The serv- 
ice associated to the property triggered by the triggering 
event is then activated and the service manipulates the 
document. A result of the service is generated from 
manipulating the document. 5 
[0035] One advantage of the present invention is that 
a document management system is provided which 
allows the user to interact directly with an electronic 
document which, unknown to the user, is preconfigured 
to automatically perform external services rather than 10 
having the user manually locate and execute an exter- 
nal service and load a target document for manipula- 
tion. 

[00361 Another advantage of the present invention is 
that a set of properties is maintained for each user inde- is 
pendently from all other users. In this manner, a first 
user can attach and maintain a set of properties for a 
first document and a second user can attach and main- 
tain a second set of properties for the same first docu- 
ment without interfering with the first user's properties of 20 
the first document. This allows different users to request 
and invoke different services independently. A docu- 
ment is not limited to one set of properties. 
[0037] Another advantage of the present invention, is 
that an external service is automatically activated in 25 
response to a triggering event where the external serv- 
ice is not limited to executing on the same machine of 
the triggering event. 

[0038] Still further advantages of the present invention 
will become apparent to those of ordinary skill in the art 30 
upon reading and understanding the following detailed 
description of the preferred embodiments. 

Prfef Description Of the D»tty|nfl ff 

35 

[0039] The following is a brief description of each 
drawing used to describe the present invention, and 
thus, are being presented for illustrative purposes only 
and should not be limitative of the scope of the present 
invention, wherein: 40 

FIGURE 1 shows a hierarchical storage mecha- 
nism compared to the concept of properties of the 
present invention; 

FIGURE 2 is a block diagram of a document man- 45 
agement system according to the present inven- 
tion, interposed within a communication channel 
between a user and an operating system; 
FIGURE 3 is a representation of a document man- 
agement system of the present invention imple- so 
mented in a computer system; 
FIGURE 4 is a configuration of the present docu- 
ment management system which allows properties 
to be attached to documents; 

FIGURE 5 illustrates a document having attached ss 
properties which are linked to external services; 
and in accordance with the present invention; and 
FIGURE 6 illustrates an exemplary block diagram of 



an operation triggering an external service. 

Detailed Description of thp Preferred EmhnHimn^ 

[0040] Prior to discussing the present invention in 
greater detail, it is believed a glossary of terms used in 
the description would be beneficial. Therefore, the fol- 
lowing definitions are set forth: 

ActiOQ: The behavior part of a property. 
Active Property: A property in which code allows 
the use of computational power to either alter the 
document or effect another change within the docu- 
ment management system. 
Arfritrqry: Ability to provide any property onto a doc- 
ument. 

Bqse Document: Corresponds to the essential bits 
of a document There is only one Base Document 
per document. It is responsible for determining a 
document's content and may contain properties of 
the document, and it is part of every principal's view 
of the document. 

Ease Properties: Inherent document properties that 
are associated with a Base Document. 
Bit Provider: A special property of the base docu- 
ment. It provides the content for the document by 
offering read and write operations. It can also offer 
additional operations such as fetching various ver- 
sions of the document, or the encrypted version of 
the content. 

Browser: A user interface which allows a user to 
locate and organize documents. 
Collection : A type of document that contains other 
documents as its content. 

Combined Po^irpftPf: A document which includes 
members of a collection and content. 
Content : This is the core information contained 
within a document, such as the words in a letter, or 
the body of an e-mail message. 
Content Document: A document which has content. 
Distributed: Capability of the system to control stor- 
age of documents in different systems (i.e., file sys- 
tems, www, e-mail sewers, etc.) in a manner 
invisible to a user. The system allows for docu- 
ments located in multi -repositories to be provided to 
a principal without requiring the principal to have 
knowledge as to where any of the document's con- 
tent is stored. 

BM$: Document Management System 
Dopument : This refers to a particular content and to 
any properties attached to the content. The content 
referred to may be a direct referral or an indirect 
referral. The smallest element of the DMS. There 
are four types of documents; Collection, Content 
Document, No-Content Document and Combined 
Document. 

Document Handle: Corresponds to a particular 
view on a document, either the universal view, or 
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that of one principal. 
DocumentID : A unique identifier for each Base 
Document. A Reference Document inherits the 
DocumentID from its referent Document identity is 
thus established via the connections between Ref- s 
erence Document References and Base Docu- 
ments. Logically, a single document is a Base 
Document and any Reference Documents that refer 
to it. 

Kernel : Manages all operations on a document. A 10 
principal may have more than one kernel. 
Multi-Principal : Ability for multiple principals to have 
their own set of properties on a Base Document 
wherein the properties of each principal may be dif- 
ferent. 15 
Notification : Allows properties and external devices 
to find out about operations and events that occur 
elsewhere in DMS. 

No Content Document : A document which contains 
only properties. 20 
Off-the-Shelf Applications : Existing applications 
that use protocols and document storage mecha- 
nisms provided by currently existing operating sys- 
tems. 

Principal : A "User" of the document management 25 
system. Each person or thing that uses the docu- 
ment management system is a principal. A group of 
people can also be a principal. Principals are cen- 
tral because each property on a document can be 
associated with a principal. This allows different 30 
principals to have different perspectives on the 
same document. 

Property : Some bit of information or behavior that 
can be attached to content. Adding properties to 
content does not change the content's identity. 35 
Properties are tags that can be placed on docu- 
ments, each property has a name and a value (and 
optionally a set of methods that can be invoked). 
Property Generator : Special case application to 
extract properties from the content of a document. 40 
Reference Document : Corresponds to one princi- 
pal's view of a document. It contains a reference to 
a Base Document (Reference Document A refers to 
Base Document B) and generally also contains 
additional properties. Properties added by a Refer- 45 
ence Document belong only to that reference; for 
another principal to see these properties, it must 
explicitly request them. Thus, the view seen by a 
principal through his Reference Document is the 
document's content (through the Base Document), so 
and a set of properties (both in the reference and 
on the Base Document). Even an owner of a Base 
Document can also have a Reference Document to 
that base, in which he places personal properties of 
the document that should not be considered an 55 
essential part of the document and placed in all 
other principal's view. 

Space: The set of documents (base or references) 



owned by a principal. 

Static Property : A name-value pair associated with 
the document. Unlike active properties, static prop- 
erties have no behavior. Provides searchable meta- 
data information about a document. 

Introduction 

[0041] As discussed in the background of the inven- 
tion, the structure that file systems provide for managing 
files becomes the structure by which users organize 
and interact with documents. However, documents and 
files are not the same thing. The present invention has 
as an immediate goal to separate management of prop- 
erties related to the document or concerning the docu- 
ment from the management of the document content. 
Therefore, user-specific document properties are man- 
aged close to the document consumer or user of the 
document rather than where the document is stored. 
Separation of the management of user properties from 
the document content itself provides the ability to move 
control of document management from a closed file sys- 
tem concept to a user-based methodology. 
[0042] FIGURE 1 illustrates a distinction between 
hierarchical storage systems whose documents are 
organized in accordance with their location described 
by a hierarchical structure and the present invention 
where documents are organized according to their 
properties (e.g. author=dourish, type-paper, sta- 
tus=draft, etc.). This means documents will retain prop- 
erties even when moved from one location to another, 
and that property assignment can have a fine granular- 
ity. 

[0043] To integrate properties within the document 
management system of the present invention, the prop- 
erties need to be presented within the content and/or 
property read/write path of a computer system, with the 
ability to both change the results of an operation as well 
as take other actions. The outline of the concept is 
described in FIGURE 2, where once user (U) issues an 
operation request (O), prior to that operation being per- 
formed by operating system (OS), a call is made to doc- 
ument management system (DMS) A of the present 
invention, which allows DMS A to function so as to 
achieve the intended concepts of the present invention. 
This includes having DMS A interact with operating sys- 
tem (OS), through its own operation request (O*). Once 
operation request (O f ) is completed, the results are 
returned (R) to DMS A which in turn presents results 
(R*) to user (U). 

[0044] With these basic concepts having been pre- 
sented, a more detailed discussion of the invention is 
set forth below. 

Document Management System (DMS) Architecture 

[0045] FIGURE 3 sets forth the architecture of a doc- 
ument management system (DMS) A of the present 
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invention in greater detail. 

Document management system (DMS) A is shown con- 
figured for operation with front-end components B, and 
back-end components C. Front-end components B 
include applications 10a-10n and I1a-11n, such as 
word processing applications, mail applications among 
others. Some of the applications are considered DMS 
aware 10a-10n which means these applications under- 
stand DMS protocols for storing, retrieving and other- 
wise interacting with DMS A. Other components are 
considered non-DMS await 11a-im. Browsers 12a 
(DMS aware) and 12b (non-DMS aware) are consid- 
ered specialized forms of applications. In order for the 
non-DMS-aware applications 11a-11n and 12b to be 
able to communicate with DMS A, front-end translator 
13 is provided. 

[0046] Similarly, back-end components C can include 
a plurality of repositories 14a-14n, where the content of 
documents are stored. Such repositories can include 
the hard disc of a principals computer, a file system 
server, a web page, a dynamic real time data transmis- 
sion source, as well as other data repositories. To 
retrieve data content from repositories 14a-14n, bit pro- 
viders, such as bit provider 16, are used. These bit pro- 
viders are provided with the capability to translate 
appropriate storage protocols. 

[0047] Principals 1-n each have their own kernel 18a- 
18n for managing documents, such as documents 20a- 
20n. Documents 20a-20n are considered to be docu- 
ments the corresponding principal 1-n has brought into 30 
its document management space. Particularly, they are 
documents that a principal considers to be of value and 
therefore has in some manner marked as a document of 
the principal. The document, for example, may be a 
document which the principal created, it maybe an e- 35 
mail sent or received by the principal, a web page found 
by the principal, a real-time data input such as an elec- 
tronic camera forwarding a continuous stream of 
images, or any other form of electronic data (including 
video, audio, text, etc.) brought into the DMS document 40 
space. Each of the documents 20a-20n have static 
properties 22 and/or active properties 24 placed ther- 
eon. 

[0048] Document 20a, is considered to be a base doc- 
ument and is referenced by reference documents 20b- 46 
20c. As will be discussed in greater detail below, in 
addition to base document 20a having static properties 
22 and/or active properties 24, base document 20a will 
also carry base properties 26 which can be static prop- 
erties 22 and/or active properties 24. Static properties so 
are shown with a "-" and active properties are shown 
with a "-o". 

[0049] Reference documents 20b-20c are configured 
to interact with base document 20a. Both base docu- 
ments and reference documents can also hold static ss 
properties 22 and/or active properties 24. When princi- 
pals 2,3 access base document 20a for the first time, 
corresponding reference documents 20b-20c are cre- 
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ated under kernels 18b- 18c, respectively. Reference 
documents 20b-20c store links 28 and 30 to unambigu- 
ously identify their base document 20a. In particular, in 
the present invention each base document is stored 
5 with a document ID which is a unique identifier for that 
document. When reference documents 20b-20c are 
created, they generate links to the specific document ID 
of their base document. Alternatively, if principal n refer- 
ences reference document 20c, reference document 
10 20n is created with a link 32 to reference document 20b 
of Principal 3. By this link principal n will be able to view 
(i.e. its document handle) the public properties principal 
3 has attached to its reference document 20c as well as 
the base properties and public reference properties of 
15 base document 20a. This illustrates the concept of 
chaining. 

[0050] The above described architecture allows for 
sharing and transmission of documents between princi- 
pals and provides the flexibility needed for organizing 
20 documents. With continuing attention to FIGURE 3. it is 
to be noted at this point that while links 28-30 are shown 
from one document to another, communication within 
DMS A is normally achieved by communication 
between kernels 18a-18n Therefore, when DMS A 
25 communicates with either front-end components B, 
back-end components C, or communication occurs 
between principals within DMS A, this communication 
occurs through kernels 18a-18n. It is however, appreci- 
ated the invention will work with other communication 
configurations as well. Using the described architecture, 
DMS A of the present invention does not require the 
principal to operate within a strict hierarchy such as in 
file or folder-type environments. Rather, properties 
22,24 which are attached to documents allows a princi- 
pal to search and organize documents in accordance 
with how the principal finds it most useful. 
[0051] For instance, if principal 1 (owner of kernel 
18a) creates a base document with content, and stores 
it within DMS A, and principal 2 (owner of kernel 18b) 
wishes to use that document and organize it in accord- 
ance with its own needs, principal 2 can place proper- 
ties on Reference Document 20b. By placement of 
these properties, principal 2 can retrieve the base docu- 
ment in a manner different than that envisioned by prin- 
cipal 1 . 

[0052] Further, by interacting with browser 12, a prin- 
cipal may run a query requesting all documents having 
a selected property. Specifically, a user may run query 
language requests over existing properties. 
[0053] Therefore, a point of the present invention is 
that DMS A manages a document space where proper- 
ties are attached by different principals such that 
actions occur which are appropriate for a particular prin- 
cipal, and are not necessarily equivalent to the organi- 
zational structure of the original author of a document or 
even to other principals. 

[0054] Another noted aspect of the present invention 
is that since the use of properties separates a docu- 
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merit's inherent identity from its properties, from a prin- 
cipal's perspective, instead of requiring a document to 
reside on a single machine, documents in essence can 
reside on multiple machines (base document 20a can 
reside on all or any one of kernels 18a-18n). Further, 5 
since properties associated with a document follow the 
document created by a principal (for example, proper- 
ties on document 20b of kernel 18b, may reference 
base document 20a), properties of document 20b will 
run on kernel 18b, even though the properties of docu- w 
ment 20b are logically associated with base document 
20a. Therefore, if a property associated with document 
20b (which references base document 20a) incurs any 
costs due to its operation, those costs are borne by ker- 
nel 18b (i.e. principal 2), since properties are main- 15 
tained with the principal who put the properties onto a 
document. 

Support for Native Applications 

20 

[0055] A DMS document interface provides access to 
documents as Java objects. Applications can make use 
of this interface by importing the relevant package in 
their Java code, and coding to the API provided for 
accessing documents, collections and properties. This 25 
is the standard means to build new DMS-aware applica- 
tions and to experiment with new interaction models. 
DMS Browser 12 (of FIGURE 3) can be regarded as a 
DMS application and is built at this level, the DMS doc- 
ument interface provides Document and Property so 
classes, with specialized subclasses supporting all the 
functionality described here (such as collections, 
access to WWW documents, etc.). Applications can 
provide a direct view of DMS documents, perhaps with 
a content-specific visualization, or can provide a wholly 35 
different interface, using DMS as a property-based doc- 
ument service back-end. 

Support for OfMhe-Shelf Applications 

40 

[0056] Another level of access is through translators 
(such as translator 13 of FIGURE 3). In an existing 
embodiment, a server implementing the NFS protocol is 
used as the translator. This is a native NFS server 
implementation in pure Java. The translator (or DMS 45 
NFS server) provides access to the DMS document 
space to any NFS client; the server is used to allow 
existing off-the-shelf applications such as Microsoft 
Word to make use of DMS documents; on PC's, DMS 
simply looks like another disk to these applications, so 
while on UNIX machines, DMS A looks like part of the 
standard network f ilesystem. 

[0057] Critically, though, what is achieved through this 
translator is that DMS A is directly in the content and 
property read/write path for existing or off-the-shelf ss 
applications. The alternative approach would be to 
attempt to post-process files written to a traditional file- 
system by applications, such as Word, that could not be 
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changed to accommodate DMS A. By instead providing 
a filesystem interface directly to these applications, it 
makes it possible to execute relevant properties on the 
content and property read/write path. Furthermore, it is 
ensured that relevant properties (such as ones which 
record when the document was last used or modified) 
are kept up-to-date. Even though the application is writ- 
ten to use filesystem information, the DMS database 
remains up to date, because DMS A is the filesystem. 
[0058] As part of its interface to the DMS database 
layer, NFS provides access to the query mechanism. 
Appropriately formatted directory names are interpreted 
as queries, which appear to "contain" the documents 
returned by the query. Although DMS provides this NFS 
service, DMS is not a storage layer. Documents actually 
live in other repositories. However, using the NFS layer 
provides uniform access to a variety of other repositor- 
ies (so that documents available over the Web appear in 
the same space as documents in a networked file sys- 
tem). The combination of this uniformity along with the 
ability to update document properties by being in the 
read and write path makes the NFS service a valuable 
component for the desired level of integration with famil- 
iar applications. It is to be appreciated that while a 
server implementing NFS protocol is discussed other 
servers could also be used. Furthermore, it is to be 
appreciated that the use of Java is only one implemen- 
tation option, and that other languages can be used. 

Property Attachment 

[0059] FIGURE 4 shows an overall system for attach- 
ing properties to a document 110. A user interface 115 
allows a user to select a desired document and select 
one or more properties to be attached to the selected 
document. A document management system A locates 
and retrieves the selected document in accordance with 
its management system protocol. In the Preferred 
Embodiment, documents are stored and retrieved 
based on their properties rather than hierarchial path 
and file names. 

[0060] In FIGURE 4, the selected document 110 is 
found to be owned by user #1 . However, the user wish- 
ing to attach a property to document 110 can be any 
user in the system. The document management system 
A maintains properties on a per user per document 
basis using individual kernels. Kernel 22 manages doc- 
uments and properties for user #1 and kernel 24 man- 
ages documents and properties for user #2. Thus, a 
user #1 can generate a set of properties 130 for docu- 
ment 110 (associated via link 35) which are independ- 
ent from the properties 140 of user #2 (associated via 
link 1 45) for document 110. 

[0061 ] A property attachment mechanism 1 50 is pro- 
vided by the document management system A which 
generates, configures and attaches properties 130 to 
the document 110 using association links 135. In the 
preferred embodiment, the document 110 is identified 
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by a unique ID and the property references the docu- 
ment using the same unique ID. The properties 130 
include static properties (represented by horizontal 
tines) and active properties (represented by circles). 
Static properties are simple name-value pairs on docu- 
ments which are relevant to a user, for example, 
"author=Joe n or "topic=interesting." An active property 
155 has a name-value and includes executable program 
code and/or instructions for automatically performing an 
operation or service without a user's involvement. Doc- 
uments can be collected, searched and retrieved based 
on static properties and/or active properties. 
[0062] The active property 155 is configured to be 
activated by a triggering event which is defined by the 
user. Attaching the active property 1 55 to the document 
110 forms an association between the property and the 
document The association is external to the data that 
represents the content of the document 110. Thus, the 
association is independent of content type, the applica- 
tion format used to generate the document and other 
characteristics of the document 110. The content of 
document 110 is controlled by a bit provider 160 which 
identifies the location of the data (eg. local disk 165, 
world wide web 170, a camera, or any data supplying 
source), indicates how the data from the sources are 
combined to form the content of the document 110, 
includes a translation interface to communicate to the 
data source, and other selected parameters which 
define the content. 

Service Invocation 

[0063] With reference to FIGURE 5, in the Preferred 
Embodiment the active property 155 is configured to 
automatically invoke an external service or program 180 
based on a triggering event. Thus, rather than having a 
user or application 185 interact directly with the service 
180 by locating and executing the service and loading 
the document 110 as an input file, the active property 
155 allows a user or application 185 to interact directly 
with the electronic document 110 and the active prop- 
erty 155 controls the activation of the service 180. 
[0064] With further reference to FIGURE 5, for exem- 
plary purposes, a user wishes to have the content of 
document 1 1 0 translated from English to French when- 
ever the user tries to "read" the document. An active 
property 155 can be attached to document 110 which 
translates the content of the document from English to 
French in response to a triggering event. The triggering 
event in this example is set to a "read content" operation 
which is applied to the document 1 1 0 by any application 
185, such as a word processor. Since the application 
185 accesses the document 110 through the document 
management system A, the document management 
system A intercepts all operations applied to document 
110 and compares them to the list of properties 130 
associated to document 110. 

[0065] As explained previously, each user maintains a 
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personal list of properties for each document whether or 
not they own the document. Before the "read content" 
operation is performed on the document 110, the oper- 
ation is checked as being a potential triggering event for 

5 an active property. In this case, active property 155 
defines the "read content" operation as a triggering 
event. Therefore, the program code of active property 
1 55 is executed which activates an external translation 
service 180. The translation service 180 executes inde- 

w pendently from the application 185 and unknown to the 
application 185. The active property 155 further func- 
tions as a communication interface between the transla- 
tion service 180 and the document management 
system A to communicate the results of the service. 

15 [0066] Here, the content of document 1 10 is manipu- 
lated by the translation service such that it is translated 
from English to French and a French version 190 is gen- 
erated as a result. Once the service is completed, rather 
than executing the "read content" operation on the orig- 

20 inal content of document 110, the document manage- 
ment system A applies the operation to the French 
version 190 and the application 185 receives the French 
translation completely unaware that the original docu- 
ment 110 is actually in English. Thus, an operation such 

25 as a "read content" command which is applied directly 
to a document, is defined to automatically invoke an 
external service without having to directly interact with 
the external service. 

[0067] With further reference to FIGURE 5, by way of 

30 another example, a triggering event can be assigned to 
an event which is not initiated by an application. Sup- 
pose a user wishes to ensure that document 110 is 
backed-up every night. Rather than requiring the user to 
run a back-up program or check the parameters of a 

35 back-up service.the user would simply attach an active 
property 157 to the document 110 which is a back-up 
property instance that controls and expresses the 
request for back-up service for the document. The back- 
up property 157 is programmed to activate a selected 

40 back-up service 1 95 which can reside on the user's sys- 
tem, a network accessed system, or other remote site 
such as on the Internet. The back-up property 157 is 
further configured to identity a triggering event which 
will cause the activation of the back-up property, for 

45 example, when the system clock becomes 12:00am. 
Once conf igured, a user or application will be unaware 
of the triggering event and will be unaware of the serv- 
ice being performed in response to the triggering event 
because the service runs independently. As further 

50 seen, property 157 can also include code to activate 
other services concurrently, such as service 180, based 
on the same triggering event. 

[0068] There are different ways of expressing a pre- 
cise service request through a property attachment. A 
55 service may be directly represented by a type of prop- 
erty instance. Thus, an Acme Back-up Service may 
include a preconfigured Acme back-up property which 
is attachable to a document which automatically invokes 
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the Acme Back-up Service upon a triggering event. On 
the other hand, a general property-like back-up may rely 
on parameters, eg. in sub-properties, to specify details 
of the request. In that case, a user may specify Acme as 
the preferred service provider for the back-up property 5 
instance. In general, specific services can rely on 
parameters. For example, the user can specify a back- 
up interval when the Acme back-up property is 
attached. 

[0069] The results of a service requested by an active 10 
property attachment can be reported or delivered to the 
user through documents and property instances in a 
number of ways: (1) Additional property instances may 
be attached to the original document. For example, the 
Acme Back-up Service might attach an Acme back-up 15 
date property to a document when a back-up copy is 
made. The property value or sub-properties would sup- 
ply the date and time of the latest copy. (2) New docu- 
ments may be generated, possibly with properties 
attached and linked to the original document through an 20 
attached property. Thus, a translation service which cre- 
ates a new document containing the translation, can 
attach a French version property to the original docu- 
ment which points to the new French version document. 
(3) The content of the original document may be modi- 25 
fied. 

[0070] Additionally, services invoked through an active 
property attachment can have effects and results that 
are not conveyed through documents and property 
instances such as: (1) arranging a certain quality of 30 
service for access to the document, (2) maintaining 
guarantees of reliability, fault tolerance, durability, etc., 
(3) direct user interaction through user interfaces imple- 
mented by the service or by code that is included in the 
active property. 35 
[0071 ] The present system includes a number of alter- 
native variations in the manner by which a service soft- 
ware comes to operate on a document once an active 
property is attached to request the service. These 
include a service query, attached code, hybrid, and a 40 
composite. Using a service query, a given service or 
program may be implemented as a long-running proc- 
ess which either routinely queries the document man- 
agement system to determine which documents have 
certain property instances attached or requests notif ica- 45 
tions of such property attachments. Upon discovering or 
being notified of a document with a new service 
request, the program or service would operate on it. 
[0072] Using attached code, the given service or pro- 
gram may supply software to be included in or refer- so 
enced by any instance of a particular property type. The 
software supplied includes entry points which may be 
called by the document management system when var- 
ious interesting/triggering events occur. For example, 
the document management system may call an entry ss 
point when the content of a document is changed. The 
service-supplied software at the entry point could then 
perform whatever steps are appropriate based on the 
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event. In particular, the service-supplied software would 
be invoked at the time when the property instance is first 
attached to a document. 

[0073] In the hybrid variation, a given service or pro- 
gram relies on both of the above methods by having the 
code included in the property instance perform notifica- 
tion of the long-running process. In such a situation, the 
communication between property code and long-run- 
ning process is determined by the service implementor. 
Under the composite variation, a given service may be 
delivered merely by combining other services or by ena- 
bling basic functionality of the document management 
system. Attaching a composite property instance would 
cause automatic attachment of several other property 
instances to invoke individual services that collectively 
provide the composite service. 

[0074] With reference to FIGURE 6, an exemplary 
block diagram of a service activation is shown. Once an 
active property is configured with a triggering event and 
executable code which initiates an external service, a 
document is capable of activating the external service. 
The triggering event can be any assigned operation or 
event which is initiated by any function on the system. 
For example, the triggering event can be initiated by an 
application, by the system, by another document by 
another active property, by a timer or any mechanism 
desired by a user. 

[0075] As an operation is applied to a document, the 
operation is intercepted 200 by the document manage- 
ment system and the operation is compared 210 to the 
properties of the document to determine whether any of 
the active properties have been defined to include the 
current operation as a triggering event 220. If the oper- 
ation triggers an active property, the program code 
associated with the active property is executed which 
activates 230 an external service. The operation can be 
any associated event such as a request from an appli- 
cation processing the document or simply a system 
event such as a date or time. 

[0076] The external service executes and, using its 
associated active property as a communication inter- 
face, accesses the document and/or the document 
management system and generates 240 a result of the 
service. A service can manipulate the target document 
by modifying its content or perform other tasks without 
modifying the target document's content, such as, mak- 
ing back-up copies of the target document, creating new 
properties for the document, etc. Once the external 
service completes its task, the original operation is then 
continued 250 if it is an executable operation, as 
opposed to simply an occurrance of a system parame- 
ter such as a timer which would have no further execu- 
tion to continue. If the content of the document was 
modified by the external service, then the operation is 
performed on the modified document rather than the 
original document. Of course, this can be changed 
based on the instructions of the active property. This 
process of activating external services is performed 
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automatically without a user's intervention and is per- 
formed independently of the user or an application 
processing the document 

[0077] Existing systems such as Windows offer users 
a way to view and control properties of files. Some of 
these properties are independent of document content, 
while others take content into account. Some property 
pages do allow users to request services such as main- 
tenance of access logs for auditing, but these services 
are simply features of the operating system itself. Con- 
versely the present system provides a mechanism for 
interaction with different external services which are 
provided independently from the operating system or 
document management system controlling the target 
document. The prior systems have shortcomings by not 
providing the generality of the present system which 
allows a user to exercise direct control over the set of 
property instances attached to a document regardless 
of the nature of the contents of that document and on a 
per user basis. 

[0078] The invention has been described with refer- 
ence to the preferred embodiment Obviously, modifica- 
tions and alterations will occur to others upon a reading 
and understanding of this specification. It is intended to 
include all such modifications and alterations insofar as 
they come within the scope of the appended claims or 
the equivalents thereof. 

Claims 

1 . A method of activating a service to be performed on 
a document in response to a triggering event, the 
method comprising the steps of: 

logically attaching a property to the document, 
the property being configured to activate a 
service for manipulating the document in 
response to the triggering event; 
associating an operation to the property as the 
triggering event, the operation being one to be 
performed on the document which is initiated 
by an application, the service being independ- 
ent from the application and capable of manip- 
ulating the document without the application 
being aware of the manipulating; 
initiating, by the application, the operation to be 
performed on the document; 
intercepting the operation before being per- 
formed on the document; 
identifying the property attached to the docu- 
ment for which the operation is the triggering 
event; 

activating the service associated to the prop- 
erty triggered by the operation, the service 
manipulating the document independent from 
the application; and 

performing the operation on the manipulated 
document. 



2. The method as set forth in claim 1 wherein the 
property is configured having instructions for acti- 
vating the service such that the service executes on 
the document and manipulates the document in 

5 response to the triggering event. 

3. The method as set forth in claim 1 wherein the doc- 
ument includes content and the manipulating 
includes changing the content of the document. 

10 

4. The method as set forth in claim 1 wherein the doc- 
ument includes content and the manipulating 
includes generating a result without changing the 
content of the document. 

15 

5. The method as set forth in claim 1 wherein the 
manipulated document is separate from the docu- 
ment. 

20 6. The method as set forth in claim 1 wherein the 
property is attached to the document such that the 
application unintentionally activates the service by 
initiating the operation to be performed on the doc- 
ument. 

25 

7. The method as set forth in claim 1 further including 
logically attaching a plurality of properties to the 
document, each of the properties being configured 
to activate a service upon a triggering event where 

30 the triggering event is an operation performed on 
the document by an application, the service being 
independent from the application. 

8. The method as set forth in claim 1 wherein the 
35 property is configured to activate a plurality of serv- 
ices in response to the triggering event. 

9. The method as set forth in claim 1 wherein the per- 
forming the operation on the manipulated docu- 

40 merit includes generating a result to the application, 
the result being different than a result which would 
be generated by the operation being performed on 
the document without activating the service. 

45 10. The method as set forth in claim 1 further including 
logically attaching a property to the document by a 
plurality of users where each property attached by 
each of the users is maintained independently for 
each of the users. 

50 

11. The method as set forth in claim 1 wherein the serv- 
ice activated is executed by an operating system 
which is different than an operating system execut- 
ing the application. 

55 

12. In a document management system, a method of 
activating a service to be performed on a document 
in response to a triggering event, the method com- 
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prising the steps of: 

logically attaching a property to the document, 
the property being configured to activate a 
service for manipulating the document in s 
response to the triggering event; 
associating the triggering event to the property 
such that the property invokes the service in 
response to an occurance of the triggering 
event; 10 
monitoring for an occurrance of the triggering 
event; 

intercepting the triggering event; 
identifying the property attached to the docu- 
ment which has the triggering event associated is 
thereto; 

activating the service associated to the prop- 
erty triggered by the triggering event, the serv- 
ice manipulating the document; and 
generating a result of the service from manipu- 20 
lating the document. 

13. The method as set forth in claim 12 wherein the 
triggering event is an operation intiated by an appli- 
cation for processing the document. 25 

14. The method as set forth in claim 12 wherein the 
triggering event is a system parameter. 

15. The method as set forth in claim 12 wherein the 30 
service routinely sends queries to the document 
management system to determine which docu- 
ments have attached properties associated to the 
service. 

35 

16. The method as set forth in claim 12 wherein the 
document includes content and the generating 
includes changing the content of the document. 

17. The method as set forth in claim 12 wherein the 40 
document includes content and the result is gener- 
ated without changing the content of the document. 
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(57) A document management system is provided 
which organizes, stores and retrieves documents 
according to properties attached to the documents. A 
property attachment mechanism allows a user to attach 
arbitrary static and active properties to a document. The 
active properties include executable code which acti- 
vates an external service in response to a triggering 
event which is predefined by the user, such as an oper- 
ation performed on the document. When the operation 
is applied to the document, the operation is compared to 
the active properties of the document to determine if it is 
a triggering event. If an active property is triggered, its 
code is executed which automatically invokes an exter- 
nal service that executes independently from the opera- 
tion. The results of the service are sent back to the 
document management system and the operation is 
then continued. In this manner, a user interacts directly 
with a document rather than locating, loading and exe- 
cuting ah external service to be applied to the docu- 
ment. The user and/or other applications are unaware 
of the external service being processed. 
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